🦋 Changeset detected

Latest commit: 9400deb

The changes in this PR will be included in the next version bump.

Not sure what this means? Click here to learn what changesets are.

Click here if you're a maintainer who wants to add another changeset to this PR

If I may, I do think this will leave SvelteKit at a significant disadvantage compared to other frameworks like Remix, which support this use case. (This is particularly/especially true when it comes to things related to auth -- which is a core need in many web applications.)

Would it be possible for enhance to simply support this use case out of the box? Both Remix and Next.js (App Router) use custom headers to detect when redirects need to be handled in a special way. (That is, they use custom headers to allow manual handling of redirects with fetch since currently fetch only allows you to follow redirects automatically.) I even rolled my own version of this logic for the Next.js Pages Router.¹ (Other frameworks may have something more sophisticated; I'm not certain.)

Would SvelteKit be able to do something similar? If not, would SvelteKit at least be able to add documentation on how to enhance enhance to support this use case? Since other frameworks support this, and since what I rolled felt pretty simple, I assumed this wouldn't be complicated. (However, I don't know the internals of SvelteKit.)

If I may, I do think this will leave SvelteKit at a significant disadvantage compared to other frameworks like Remix, which support this use case. (This is particularly/especially true when it comes to things related to auth -- which is a core need in many web applications.)

Would it be possible for enhance to simply support this use case out of the box? Both Remix and Next.js (App Router) use custom headers to detect when redirects need to be handled in a special way. (That is, they use custom headers to allow manual handling of redirects with fetch since currently fetch only allows you to follow redirects automatically.) I even rolled my own version of this logic for the Next.js Pages Router.1 (Other frameworks may have something more sophisticated; I'm not certain.)

Would SvelteKit be able to do something similar? If not, would SvelteKit at least be able to add documentation on how to enhance enhance to support this use case? Since other frameworks support this, and since what I rolled felt pretty simple, I assumed this wouldn't be complicated. (However, I don't know the internals of SvelteKit.)

Footnotes

1. See also the middleware and response helper that complimented the client-side utility which I linked to. ↩

If we do decide to support non-SvelteKit actions, this error should still be helpful in the meantime (until support is added).

If I may, I do think this will leave SvelteKit at a significant disadvantage compared to other frameworks like Remix, which support this use case. (This is particularly/especially true when it comes to things related to auth -- which is a core need in many web applications.)
Would it be possible for enhance to simply support this use case out of the box? Both Remix and Next.js (App Router) use custom headers to detect when redirects need to be handled in a special way. (That is, they use custom headers to allow manual handling of redirects with fetch since currently fetch only allows you to follow redirects automatically.) I even rolled my own version of this logic for the Next.js Pages Router.1 (Other frameworks may have something more sophisticated; I'm not certain.)
Would SvelteKit be able to do something similar? If not, would SvelteKit at least be able to add documentation on how to enhance enhance to support this use case? Since other frameworks support this, and since what I rolled felt pretty simple, I assumed this wouldn't be complicated. (However, I don't know the internals of SvelteKit.)

Footnotes

1. See also the middleware and response helper that complimented the client-side utility which I linked to. ↩

If we do decide to support non-SvelteKit actions, this error should still be helpful in the meantime (until support is added).

That's fair. If the Svelte team decides that it's worth pursuing this at some point (even if it's in the more-distant future), could #10855 be unlinked from this PR? (I understand that the team may not have made a decision on this yet.)